In Java, exceptions are broadly classified as:

·    Checked Exceptions

·     Unchecked Exceptions

Sometimes, the checked exceptions are also called compile-time exceptions because our code would not compile if we do not handle a checked exception. All unchecked exceptions need not be caught in the program and the code would compile even when they are not caught. Refer once again to the Exception class hierarchy;

·   All exceptions that come under IOException (including IOException itself) are called checked exceptions.

·     All other exceptions that come under RuntimeException, including itself, and all subclasses of Error, including itself, are unchecked exceptions and do not require us to provide a handler in our code.

 When a checked exception occurs in a method, the method must either catch the exception and take the appropriate action, or pass the exception on to its caller. Thus, checked exceptions force programmers to deal with an exception that may be thrown at runtime. Examples of checked exceptions include:

·         NoSuchFieldException
·         ClassNotFoundException
·         NoSuchMethodException.

In the program implemented in the previous post, we used file handling and network programming. The use of these classes forced us to provide exception handlers. These are examples of checked exceptions.

In case of unchecked exceptions, the compiler does not force the programmer to catch the exception or to declare it in a throws clause (discussed later). The programmer need not even know that the exception could be thrown at runtime. Examples of unchecked exceptions are:

·         IndexOutOfBoundsException
·         ArrayIndexOutOfBoundsException
·         ClassCastException
·         ArithmeticException.

Although the compiler does not force us to provide a handler for unchecked exceptions, we could still provide one, if we want to.

The throws Construct

Due to the requirement to handle checked exceptions, we may have to insert the exception handler in our program at several places. This distribution of exception handlers throughout our program may clutter our code and make us lose focus on our core program logic. Also, in some situations, we may not want to handle an exception in the place where it is thrown. This is as good as saying, “I have generated an error. I do not know what to do with it, so I am passing along the details so we can take care of it.” Java enables us to centralize our exception-handling code. With this facility, a method encapsulating the suspect code may simply pass on the exception information to its caller and without worrying about handling the exception. The caller, in turn, can pass on the generated exception information to its caller, and so on. Ultimately, the topmost calling method must handle the exception; otherwise, the result is a compilation error (because a checked exception is not caught anywhere in the program). This feature is provided with the help of the throws keyword.